Managing negotiation of extended idle mode discontinuous reception parameters between a user equipment and a core network device

ABSTRACT

The disclosed subject matter provides techniques for managing negotiation of extended discontinuous reception (eDRX) parameters between a user equipment (UE) and core network device of a wireless communication network. In one embodiment, a method is provided that includes establishing, by a device comprising a processor, a wireless communication link with a network device of a wireless network. The method can further include determining, by the device, based on a determination that an idle mode retry protocol for the device is enabled, a number of times the network device has previously instructed the device to use a network value for an idle mode parameter instead of a device value for the idle mode parameter in association with the device operating in an idle mode.

TECHNICAL FIELD

The disclosed subject matter relates to techniques for managing thenegotiation of extended idle mode discontinuous reception (eDRX)parameters between a user equipment (UE) and core network device.

BACKGROUND

Under the umbrella of third generation partnership project (3GPP)wireless communication technology standards, radio-access technologiesfor mobile broadband have evolved effectively to provide connectivity tobillions of subscribers and devices. Within this ecosystem, thestandardization of a radio technology for massive machine-typecommunication (MTC) applications is also evolving. The aim is for thistechnology to provide cost-effective connectivity to billions of“Internet of things” (IoT) devices, supporting low power consumption,the use of low-cost devices, and provision of excellent coverage.

One mechanism used to save user equipment (UE) power in LTE and advancedLTE cellular networks is discontinuous reception (DRX). With DRX, a canbe configured to turn at least part of its circuitry off during a DRXperiod to save power. During the DRX period, the network should not tryto contact the UE, so the UE does not need to listen for the pagingmessages or downlink control channels used by the network to reach theUE. Accordingly, the UE turns off its transmitter and receiver fordefined intervals, referred to as DRX periods. Between DRX periods, theUE can turns on its receiver for a short paging period. The initial DRXoperating parameters limit the longest possible DRX period to 2.56seconds. The 3GPP Release 13 specification improves upon the originalDRX mode by introducing an extended idle mode DRX (eDRX). With eDRX, theUE and the network can negotiate the eDRX parameters that control theduration of the DRX cycle beyond the previous upper limit of 2.56 tooptimize UE power consumption while balancing network signaling needs.However, current techniques employed to negotiate eDRX parametersbetween the UE and the network impart an unnecessary load on thenetwork.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is an illustration of an example wireless communication systemthat facilitates managing negotiation of eDRX parameters between a UEand core network device in accordance with various aspects andembodiments of the subject disclosure.

FIG. 2 provides a graphical illustration demonstrating principles ofeDRX in accordance with various aspects and embodiments of the subjectdisclosure.

FIG. 3 provides a signaling diagram demonstrating a procedure fornegotiating eDRX parameters between a UE and a core network device inaccordance with various aspects and embodiments of the subjectdisclosure.

FIG. 4 provides a flow diagram of an example method for managingnegotiation of eDRX parameters between a UE and core network device inaccordance with various aspects and embodiments of the subjectdisclosure.

FIG. 5 presents an example UE configured to employ an eDRX retryprotocol in association with negotiating eDRX parameters between the UEand the network in accordance with various aspects and embodiments ofthe subject disclosure.

FIG. 6 presents an example network device configured to facilitatemanaging negotiation of eDRX parameters between a UE the network devicein accordance with various aspects and embodiments of the subjectdisclosure.

FIG. 7 illustrates another example method for managing negotiation ofeDRX parameters between a UE and core network device in accordance withvarious aspects and embodiments of the subject disclosure.

FIG. 8 illustrates another example method for managing negotiation ofeDRX parameters between a UE and core network device in accordance withvarious aspects and embodiments of the subject disclosure.

FIG. 9 illustrates another example method for managing negotiation ofeDRX parameters between a UE and core network device in accordance withvarious aspects and embodiments of the subject disclosure.

FIG. 10 depicts an example schematic block diagram of a computingenvironment with which the disclosed subject matter can interact.

FIG. 11 illustrates an example block diagram of a computing systemoperable to execute the disclosed systems and methods in accordance withan embodiment.

DETAILED DESCRIPTION

Extended idle mode discontinuous reception (eDRX) is a 3GPP Release 13feature that allows for reducing device power consumption while beingavailable for mobile terminated data within a certain delay. eDRX allowsa UE to extend the duration of respective DRX periods during idle modebeyond a previous DRX period limit of 2.56 seconds up to 43.69 minutes.The 3GPP release 13 also allows a UE and the core network to negotiateeDRX parameters, including the duration of the respective DRX periods.In particular, as described in 3GPP Release 13, in order to enter eDRXmode, the UE shall request the use of eDRX during an attachmentprocedure or tracking area update (TAU) procedure by including desiredeDRX parameters in the attach request or the TAU request. The eDRXparameters include a value for a DRX timer that defines the duration ofthe DRX periods. For example, this value includes a defined valuedselected from a set of defined values that are power of 2, starting from5.12 seconds (e.g., 5.12 seconds, 10.24 seconds, 20.48 seconds and soon) up to a maximum of 2621.44 seconds (e.g., 43.69 min). The networkcan authorize a UE to operate using the requested eDRX by responding tothe UE attach or TAU request and including eDRX parameters in theresponse. In particular, as defined in 3GPP Release 13 (e.g., technicalspecification (TS) 23.682 and TS 24.301), the UE shall only operateusing eDRX mode if the network provides eDRX parameters when acceptingan attach request or TAU request. Otherwise, the UE shall apply itsregular DRX configuration (e.g., wherein the DRX duration is 2.56seconds or less, as defined in 3GPP TS 23.401 clause 5.13).

In some scenarios, the eDRX parameters provided by the network to the UE(referred to herein as the network eDRX parameters) in an attachment orTAU acceptance response are different from the eDRX parameters requestedby the UE in the attach/TAU request (referred to herein as the UE eDRXparameters). For example, a UE may be configured to request a defaultmaximum DRX period (e.g., 43.69 minutes) in order to conserve power.However, based on signal scheduling constraints, the network maydetermine that the UE should not apply the requested UE DRX timer butapply shorter DRX timer (e.g., about 30 minutes). Accordingly, in somescenarios, the network attachment or TAU acceptance response canauthorize the UE to operate using eDRX but direct the UE to employnetwork defined eDRX parameters that are different from the UE requestedeDRX parameters.

The 3GPP specification requires the UE to always honor the networkprovided eDRX parameters, even if they are different that the eDRXparameters requested by the UE. However, the 3GPP specification onlyrequires the UE apply the network provided eDRX parameters until thenext attach/TAU event. In particular, the 3GPP specification requiresthe UE to include eDRX parameters in each attach or TAU procedure if theUE wishes to use eDRX mode, regardless as to whether the UE waspreviously using eDRX mode. As with the initial attach/TAU request, asdefined in the 3GPP specification, the UE and the core network cannegotiate the eDRX parameters in each subsequent attach/TAU request,even if the previous negotiation resulted in the network providingdifferent eDRX parameters than that requested by UE. For example, inevery subsequent attach/TAU request sent by the UE, if the UE desires tooperate using eDRX, the UE can include UE desired eDRX parameters in theattach/TAU request, even if the network previously denied usage of theUE desired eDRX parameters and directed the UE to use different networkeDRX parameters. The 3GPP specification doesn't define how to manage thenegotiation of eDRX parameters between UE and the core network. As aresult, in many scenarios, there can be a continuous deadlock whereinthe UE continuously requests preferred UE eDRX parameters in eachattach/TAU request and the network continuously responds with networkeDRX parameters that are different from the preferred UE eDRXparameters. This type of deadlock scenario causes unnecessary strain onthe network which can be exponentially exacerbated as the number ofdevices the network regularly negotiates eDRX parameters with grows.

The subject disclosure is directed to computer processing systems,computer-implemented methods, apparatus and/or computer program productsthat facilitate managing negotiation of eDRX parameters between a UE andcore network device. In particular, the subject disclosure describes amechanism that involves deploying an eDRX retry protocol at the UE. Theproposed eDRX retry protocol provides a solution to guide the UE/chipsetto honor the network provided eDRX parameters after reaching the maximumnumber of attempts to negotiate UE preferred eDRX parameters, referredto herein as a “retry” attempt. With the subject UE based eDRX retryprotocol, the network can continue to control eDRX parameters employedby respective UEs serviced by the network. Thus, the network cancontinue to optimize network provided eDRX parameters in view of bothcurrent network and current device requirements. At the same time, thenetwork processing load associated with determining whether to authorizeUE requested eDRX parameters in view of network logistics will belowered. For example, after the maximum number of retry attempts isreached, the UE can be configured to stop requesting UE preferred eDRXparameters in attachment and TAU requests. The UE can simply include thepreviously provided network eDRX parameters in the attachment and TAUrequests. Thus the network will not need to re-evaluate the UE requestedeDRX parameters and directly respond to the attachment or TAU requestwith the requested network eDRX parameters, (which the network hadpreviously authorized the UE to employ), thereby reducing dataprocessing and power consumption by the network.

In addition, the subject retry mechanism allows the network to controlthe eDRX retry protocol employed by the UE based on network load. Forexample, the network can control enabling and disabling the retryprotocol as well as the maximum number off retry attempts allowed. Insome embodiments, the eDRX retry protocol can be implemented on thenetwork provided/configured subscriber identity module (SIM) card oruniversal integrated circuit card (UICC) of the UE. According to theseembodiments, the network can control the eDRX retry protocol using overthe air (OTA) messaging protocol. From UE side, the UE will begin usingnetwork preferred eDRX parameters after a certain number of retryattempts. The UE can further log information regarding network preferredeDRX parameters. This logged information can be sent to and employed bychipset vendors or device vendors to analyze and optimize their designfor certain applications.

In one or more embodiments, a method is provided that includesestablishing, by a device comprising a processor, a wirelesscommunication link with a network device of a wireless network. Themethod further includes determining, by the device, based on adetermination that an idle mode retry protocol for the device isenabled, a number of times the network device has previously instructedthe device to use a network value for an idle mode parameter instead ofa device value for the idle mode parameter in association with thedevice operating in an idle mode. In some implementations the method canfurther include, in response to a determination that the number of timesdoes not exceed a threshold retry number, sending, by the device to thenetwork device, a request to use the device value for the idle modeparameter in association with the device operating in the idle mode. Inan aspect, the sending the request comprises sending an attachmentmessage to the network device via the wireless communication link, andwherein the attachment request comprises the device value for the idlemode parameter. In another aspect, the sending the request comprisessending a tracking area update message to the network device via thewireless communication link, and wherein the tracking area updatemessage comprises the device value for the idle mode parameter in the

.

In other implementations, the method can further include, in response adetermination that the number of times exceeds a threshold retry number,sending, by the device to the network device, a request to use thenetwork value for the idle mode parameter in association with the deviceoperating in the idle mode. In accordance with various embodiments, thenetwork value for the idle mode parameter was previously received by thedevice from the network device in response to a previous request, sentby the device to the network device, for authorization to use the devicevalue for the idle mode parameter in association with the deviceoperating in the idle mode, and wherein the device previously employedthe network value for the idle mode parameter in association with thedevice operating in the idle mode.

In another embodiment, an integrated circuit card device is providedthat comprises a processor, and a memory that stores executableinstructions that, when executed by the processor, facilitateperformance of operations. These operations can comprise, based on adetermination that an idle mode retry protocol is enabled, determining anumber of times a device, operatively coupled to the integrated circuitcard device, was previously instructed by a network device of a wirelesscommunication network to use a network value for an idle mode parameterinstead of a device value for the idle mode parameter in associationwith the device operating in an idle mode. These operations can furthercomprise, directing the device to send a first request to the networkdevice requesting usage of the device value in association with theoperating in the idle mode based on the number being less than athreshold retry number, and directing the device to send a secondrequest to the network device requesting usage of the network value inassociation with the operating in the idle mode based on the numberbeing greater than or equal to a threshold retry number. In someembodiments, the integrated circuit card device is a SIM card of thedevice. In other embodiments, the integrated circuit card device is aUICC of the device.

In yet another embodiment a machine-readable storage medium, comprisingexecutable instructions that, when executed by a processor of a device,facilitate performance of operations. These operations can includedetermining a number of times the device was previously instructed by anetwork device of a wireless communication network to use a networktimer value for a discontinuous reception period of and idle modeinstead of a device timer value for the discontinuous reception periodin association with the device operating in the idle mode. Theoperations further comprise, sending a first request to the networkdevice requesting usage of the device timer value in association withthe device operating in the idle mode based on the number being lessthan a threshold retry number. In various implementations, theoperations can further comprise, sending a second request to the networkdevice requesting usage of the network timer value in association withthe device operating in the idle mode based on the number being lessgreater than or equal to the threshold retry number.

The subject disclosure is now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. The following description and the annexed drawings set forthin detail certain illustrative aspects of the subject matter. However,these aspects are indicative of but a few of the various ways in whichthe principles of the subject matter can be employed. Other aspects,advantages, and novel features of the disclosed subject matter willbecome apparent from the following detailed description when consideredin conjunction with the provided drawings. In the following description,for purposes of explanation, numerous specific details are set forth inorder to provide a thorough understanding of the subject disclosure. Itmay be evident, however, that the subject disclosure may be practicedwithout these specific details. In other instances, well-knownstructures and devices are shown in block diagram form in order tofacilitate describing the subject disclosure.

FIG. 1 is an illustration of an example wireless communication system100 that facilitates managing negotiation of eDRX parameters between aUE and core network device in accordance with various aspects andembodiments of the subject disclosure. Aspects of the systems,apparatuses or processes explained in this disclosure can constitutemachine-executable component(s) embodied within machine(s), e.g.,embodied in one or more computer readable mediums (or media) associatedwith one or more machines. Such component(s), when executed by the oneor more machines, e.g., computer(s), computing device(s), virtualmachine(s), etc. can cause the machine(s) to perform the operationsdescribed.

The wireless communication system 100 can be or include various types ofdisparate networks, including but not limited to: cellular networks,femto networks, picocell networks, microcell networks, internet protocol(IP) networks Wi-Fi service networks, broadband service network,enterprise networks, cloud based networks, and the like. System 100 cancomprise one or more UEs 102, a network node 104 and a core wirelesscommunication network 106. It should be appreciated that a single UE 102is depicted for exemplary purposes and that any number of UEs can beincluded in system 100. The UE 102 can include a variety of differentmobile and stationary device types that can be configured to operateusing eDRX mode and the subject eDRX retry protocol. For example, the UE102 can include but is not limited to: a cellular phone, a smartphone, atablet computer, a wearable device, a virtual reality (VR) device, aheads-up display (HUD) device, and the like. In various exemplaryembodiments, the UE 102 can be configured with MTC or machine to machine(M2M) capabilities. In particular, eDRX will have a strong impact on MTCdevices (e.g., Category-M1 devices (Cat-M1), Cat-M2 devices, narrowband(NB)-IoT devices, Cat-0 devices, Cat-1 devices and the like). Forexample, the UE 102 can be or include metering devices, implantablemedical device (IMDs), sensor and/or control devices associated withhome automation systems, tracking devices, point of sale devices (e.g.,vending, machines), security devices (e.g., associated with surveillancesystems, homes security, access control, etc.), and the like. The termsMTC and M2M are used herein interchanged. A UE that is configured toperform one or more MTC functionalities is referred to herein as an MTCdevice.

The UE 102 can be configured to communicate with the core wirelesscommunication network 106, and more particularly one or more networkdevices 108 of the core wireless communication network 106, using acommunication link established between the UE 102 and a network node 104of the wireless communication network. The network node 104 can beconnected to the core wireless communication network 106 (or one or morenetwork devices 108 of the core wireless communication network 106) viaone or more backhaul links (indicated by the thick arrow line). Forexample, the one or more backhaul links can include wired linkcomponents, such as but not limited to: like a T1/E1 phone line, adigital subscriber line (DSL) (e.g., either synchronous orasynchronous), an asymmetric DSL (ADSL), an optical fiber backbone, acoaxial cable, and the like. The one or more backhaul links can alsoinclude wireless link components, such as but not limited to,line-of-sight (LOS) or non-LOS links which can include terrestrialair-interfaces or deep space links (e.g., satellite communication linksfor navigation). The thin solid arrow line from the UE 102 to thenetwork node 104 represents uplink communications and the thin dashedarrow line from the network node 104 to the UE 102 represents downlinkcommunications. Communication links between a UE and a network accesspoint device, such as network node 104, are referred to herein asmachine-to-network (M2N) communication links. In some implementations,the UE 102 can be configured to communicate with one or more other UEsanother using a machine-to-machine (M2M) link. Further, in someimplementations, a UE 102 can serve as a network access point device toother UEs via which the other UEs can communicate with the network node104.

The non-limiting term network node (or radio network node) is usedherein to refer to any type of network node serving a UE 102 and/orconnected to other network node, network element, or another networknode from which the UE 102 can receive a radio signal. Examples ofnetwork nodes (e.g., network node 104) can include but are not limitedto: NodeB devices, base station (BS) devices, access point (AP) devices,and radio access network (RAN) devices. The network node 104 can alsoinclude multi-standard radio (MSR) radio node devices, including but notlimited to: an MSR BS, an eNode B, a network controller, a radio networkcontroller (RNC), a base station controller (BSC), a relay, a donor nodecontrolling relay, a base transceiver station (BTS), a transmissionpoint, a transmission nodes, an RRU, an RRH, nodes in distributedantenna system (DAS), and the like.

The wireless communication system 100 can employ various wirelesscommunication technologies and modulation schemes to facilitate wirelessradio communications between devices (e.g., between UEs 102 and betweenUEs 102 and the network node 104, between the network node 104 and oneor more network devices 108, etc.). For example, the UEs 102 can beconfigured to communicate with the network node 104, and vice versausing various wireless communication technologies, including but notlimited to: Universal Mobile Telecommunications System (UMTS)technologies, LTE technologies, advanced LTE technologies (includingvoice over LTE or VoLTE), narrowband IoT (NB-IoT), Code DivisionMultiple Access (CDMA) technologies, Time Division Multiple Access(TDMA) technologies, Orthogonal Frequency Division Multiplexing (OFDN)technologies, Filter Bank Multicarrier (FBMC) technologies, WirelessFidelity (Wi-Fi) technologies, Worldwide Interoperability for MicrowaveAccess (WiMAX) technologies, General Packet Radio Service (GPRS)technologies, Enhanced GPRS, technologies, Third Generation PartnershipProject (3GPP) technologies, Fourth Generation Partnership Project(4GPP) technologies, Fifth Generation Partnership Project (SGPP)technologies, Ultra Mobile Broadband (UMB) technologies, High SpeedPacket Access (HSPA) technologies, Evolved High Speed Packet Access(HSPA+), High-Speed Downlink Packet Access (HSDPA) technologies,High-Speed Uplink Packet Access (HSUPA) technologies, ZIGBEE®technologies, or another IEEE 802.XX technology. Additionally,substantially all aspects disclosed herein can be exploited in legacytelecommunication technologies. In some embodiments, the UEs can beconfigured to communicate with one another (e.g., via M2M links) usingsuitable local area network (LAN) or personal area network (PAN)communication technologies and configured to communicate with thenetwork node 104 using suitable WAN communication technologies. Forexample, in one or more embodiments, the UEs 102 can be configured tocommunicate with one another using BLUETOOTH®, BLUETOOTH® low energy(BLE), near field communication (NFC), Wi-Fi protocol, ZIGBEE®, RF4CE,WirelessHART, 6LoWPAN, Z-Wave, ANT, and the like. The one or more UEs102 can be further configured to communicate with the network node 104using one or more of the radio access network (RAN) technologies listedabove (e.g., LTE, VoLTE, UMTS, etc.).

The core wireless communication network 106 can include various networkdevices 108 that facilitate providing wireless communication services tothe UEs 102 via the network node 104 and/or various additional networkdevices (not shown). For example, the one or more network devices 108 ofthe core wireless communication network 106 can include but are notlimited to: mobile switching center (MSCs) devices, a home locationregister (HLR) device, a visitor location register (VLR) device,authentication center (AUC) devices, provisioning servers, billingservers, operation and support system (OSS) devices, short messageservice center (SMSC) devices, and many other elements. In someimplementations, the one or more network devices 108 includes a mobilitymanagement entity (MME) device. For example, the system architectureevolution (SAE) is the core network architecture of 3GPP's LTE wirelesscommunication standard. In accordance with SAE, the MME is the keycontrol-node for the LTE access-network. The MME is involved in thebearer activation/deactivation process and is also responsible forchoosing the serving gateway (SGW) for a UE at the initial attach, theTAU procedure, and at time of intra-LTE handover involving core network(CN) node relocation. The MME is also responsible for idle mode UEpaging and tagging procedure including retransmissions. In variousembodiments, the MME can also be configured to control eDRX parameternegotiation between the UE and the core wireless communication network106 in accordance with various aspects and embodiments disclosed herein.

In accordance with various aspects and embodiments described herein,system 100 can be configured to facilitate managing eDRX parameternegotiation between the UE 102 and the core wireless communicationnetwork 106 that provides at least some wireless communication servicesto the UE via an M2N connection between the UE 102 and the network node104. In one or more embodiments, the UE 102 is configured to operateusing eDRX mode.

FIG. 2 provides a graphical illustration 200 demonstrating principles ofeDRX in accordance with various aspects and embodiments of the subjectdisclosure. The eDRX mode is an idle mode between transmission eventswherein the UE turns off its transmitter and receiver for definedintervals. These defined intervals are referred to herein as DRX periodswhen they are 2.56 seconds or less and eDRX periods when they aregreater than 2.56 seconds. For example, the initial DRX operatingparameters limit the longest possible DRX period to 2.56 seconds. The3GPP Release 13 specification improves upon the original DRX mode witheDRX mode wherein the eDRX periods can range from 5.12 seconds up to amaximum of 2621.44 seconds (e.g., 43.69 min). An eDRX parameter referredto herein as the eDRX timer controls the duration of the eDRX periods.According to the 3GPP specification Release 13, the eDRX timer can be adefined valued selected from a set of defined values that are power of2, starting from 5.12 secondsup to a maximum of 2621.44 seconds (e.g.,5.12 seconds, 10.24 seconds, 20.48 . . . 2621.44 seconds). Between eDRXperiods, the UE temporarily UE turns on its receiver for a short pagingperiod to listen for the paging messages or downlink control channelsused by the network to reach the UE. For example, a normal LTE pagingperiod is 1.28 seconds. In some implementations, the UE alternatesbetween activating and deactivating its receiver over the duration ofthe paging period. In other implementations, the UE can maintainactivation of its receiver over the duration of the paging period. Inaddition to providing DRX periods that can range from about 5 seconds toabout 45 minutes, with eDRX, the UE and the network can negotiate theeDRX parameters that control the eDRX operations of the UE.

For example, FIG. 3 provides a signaling diagram 300 demonstrating aprocedure for negotiating eDRX parameters between a UE and a corenetwork device in accordance with various aspects and embodiments of thesubject disclosure. In the embodiment shown, the core network deviceincludes an MME device. An eNodeB (eNB) serves as the network node(e.g., network node 104) that communicatively connects the UE with theMME.

As described in 3GPP Release 13, in order to enter eDRX mode, the UEshall request the use of eDRX during an attachment procedure or trackingarea update (TAU) procedure by including eDRX parameters in the attachrequest or the TAU request, as shown in signaling event 302. In someimplementations, these eDRX parameters can include UE eDRX parametervalues that are desired or preferred by the UE. For example, the UEpreferred eDRX parameter values can include default UE eDRX parametersvalues programmed into the UE. In another example, the UE preferred eDRXparameter values can include eDRX parameter values determined by the UEbased on various operations of the UE. In other implementations, asdescribed in greater detail infra, the eDRX parameter values provided bythe UE in the attach/TAU request will include previously providednetwork eDRX parameter values if the UE has reached the maximum amountof eDRX negotiation retries. In various embodiments, the eDRX parametersinclude an eDRX timer value. For example, the eDRX timer value caninclude a defined timer value selected from a set of defined time values(e.g., (e.g., 5.12 seconds, 10.24 seconds, 20.48 . . . 2621.44 seconds).In some embodiments, the UE and the core network can also negotiateother eDRX parameters including but not limited to: the number of eDRXperiods between transmission events (e.g., the total duration of theidle period), the duration of the paging period, and the receiveractivating schedule during the paging period.

The network can authorize a UE to operate using eDRX mode by respondingto the UE attach or TAU request and including eDRX parameter values inthe response, as shown in signaling event 304. The UE then disconnectsfrom the eNB as shown in signaling event 306 (e.g., via a radio resourcecontrol (RCC) connection release) and begins operating in the eDRX idlemode 308 according to the eDRX parameter values received from the MME inthe attach/TAU accept message. In particular, as defined in 3GPP Release13 (e.g., technical specification (TS) 23.682 and TS 24.301), the UEshall only operate using eDRX mode if the network provides eDRXparameters when accepting an attach request or TAU request. Otherwise,the UE shall apply its regular DRX configuration (e.g., wherein the DRXduration is 2.56 seconds or less, as defined in 3GPP TS 23.401 clause5.13).

With reference to FIGS. 1, 2 and 3, in some scenarios, the network eDRXparameter values provided to the UE 102 by the network device (e.g., anetwork device 108, such as an MME device) in an attachment or TAUacceptance response (e.g., signaling event 304) are different from theeDRX parameter values requested by the UE in the attach/TAU request. The3GPP specification requires the UE 102 to always honor the networkprovided eDRX parameters, even if they are different that the eDRXparameters requested by the UE. However, the 3GPP specification onlyrequires the UE 102 apply the network provided eDRX parameters until thenext attach/TAU event. For example, according to the 3GPP specification,in every subsequent attach/TAU request sent by the UE 102, if the UEdesires to operate using eDRX, the UE 102 can include UE desired eDRXparameters in the attach/TAU request, even if the network previouslydenied usage of the UE desired eDRX parameters and directed the UE touse different network eDRX parameters. The 3GPP specification does notdefine how to manage the negotiation of eDRX parameters between UE andthe core network. As a result, in many scenarios, there can be acontinuous deadlock wherein the UE continuously requests preferred UEeDRX parameters in each attach/TAU request and the network continuouslyresponds with network eDRX parameters that are different from thepreferred UE eDRX parameters. This type of deadlock scenario causesunnecessary strain on the network, which can be exponentiallyexacerbated as the number of devices the network regularly negotiateseDRX parameters with grows.

In order to mitigate the aforementioned deadlock scenario, in accordancewith various embodiments of the subject disclosure, the UE 102 canfurther be configured with eDRX retry control functionality. The eDRXretry control functionality provides an eDRX retry protocol that whenexecuted by a processor of the UE 102, controls the maximum number oftimes (referred to herein as N-max) the UE 102 can negotiate UE desiredeDRX parameters with the core wireless communication network 106, (e.g.,via a network device 108 of the core wireless communication network 106,such as an MME device), after the network has previously instructed theUE 102 to use network eDRX parameters that are different from the UErequested eDRX parameters. For example, in accordance with the eDRXretry control protocol, the UE 102 can track the number of times N theUE requests eDRX parameters in attach and TAU procedures yet is directedby the network 106 (e.g., a network device 108 of the core wirelesscommunication network 106, such as an MME device) to employ network eDRXparameters that are different from the UE requested eDRX parameters. Inassociation with each new attach or TAU procedure, based on the eDRXretry control protocol, the UE 102 can determine whether the number oftimes N, (that the UE was directed by the core wireless communicationnetwork 106 to employ network eDRX parameters after requesting differentUE eDRX parameters), is greater than or equal to N-max (the maximumretry amount). If N is not greater than or equal to N-max, then the UE102 can include its preferred UE eDRX parameters in the attach or TAUrequest.

However, if N is greater than or equal to N-max, based on the retryprotocol, the UE can be configured to include the previously providednetwork eDRX parameters in the attach or TAU request. As a result, inresponse to reception of the attach or TAU request, the core wirelesscommunication network 106 (e.g., a network device 108 of the corewireless communication network 106, such as an MME device) will not needto determine whether the network should authorize the UE to apply itsrequested UE eDRX parameters. The network will merely see the UE isrequesting usage of eDRX parameters that have already been authorized bythe network, skip the negotiation process, and direct the UE to employthe requested network eDRX parameters in the networks attach accept orTAU accept message. The UE 102 can also continue to provide the networkeDRX parameters in each subsequent attach or TAU request if the UEdesires to operate using eDRX unless the UE is power cycled, re-booted,reset, enters and exits airplane mode or the like, which can result insetting N back to its default value (e.g., zero).

In addition, in some embodiments, the core wireless communicationnetwork 106 can control the eDRX retry protocol employed by the UE basedon network load, signal scheduling constraints, UE power and servicerequirements, and other possible factors. For example, the network cancontrol enabling and disabling the eDRX retry protocol on the UE as wellas the maximum number off retry attempts allowed (N-max). In anotherexample, the core wireless communication network 106 can reset thenumber of UE eDRX retry negotiation attempts (N). In some embodiments,the eDRX retry protocol can be implemented on the networkprovided/configured subscriber identity module (SIM) card or universalintegrated circuit card (UICC) of the UE. According to theseembodiments, the core wireless communication network 106 can control theeDRX retry protocol of the UE using over the air (OTA) messagingprotocol. For example, the UE can include a SIM card or UICC that hasbeen programmed to include the subject eDRX retry control functionality.In one implementation, the eDRX retry control functionality can includean eDRX retry flag that can be set to one of two possible values,wherein a first value (e.g., one) can enable the eDRX retryfunctionality and a second value (e.g., zero) can disable the eDRX retryfunctionality. The core wireless communication network 106 can furthercontrol enablement and disablement of the eDRX retry functionality ofthe UE 102 by sending the UE an OTA message, via a communication linkestablished between the network node 104 and the UE 102, that directsthe UE to set the retry flag to either the first value or the secondvalue. In another implementation, the eDRX retry control protocol on theUE SIM/UICC can define a value for N-max. The core wirelesscommunication network 106 can also set the value for N-max using an OTAmessage sent to the UE 102.

FIG. 4 provides a flow diagram of an example method 400 for managingnegotiation of eDRX parameters between a UE and core network device inaccordance with various aspects and embodiments of the subjectdisclosure. In one or more embodiments, method 400 is performed by a UE(e.g., UE 102) in association with operating in a wireless communicationnetwork (e.g., system 100). Repetitive description of like elementsemployed in respective embodiments is omitted for sake of brevity.

At 402, the UE initiates an attach or TAU procedure 402. For example,the UE can activate its transmitter and receiver and establish awireless communication link with a network node (e.g., network node 104)of a wireless communication network that the UE is subscribed to orotherwise authorized to connect to. In association with initiating theattach or TAU procedure, at 404, the UE determines whether an eDRX retryprotocol functionality of the UE is enabled. For example, the UE cancheck to see whether an eDRX retry flag of the UE is set to an enabledvalue (e.g., one) or a disabled value (e.g., zero). If the eDRX retryprotocol is disabled, then the UE can include UE preferred eDRXparameters in the attach or TAU request, as indicated at 406. If howeverthe eDRX retry protocol is enabled, then at 408, the UE determineswhether the number of eDRX negotiation retries (N) exceeds N-max (themaximum number of eDRX negotiation retries the UE is authorized toperform). If at 408, N does not exceed N-max, then the UE can include UEpreferred eDRX parameters in the attach or TAU request, as indicated at410. If however N does exceed N-max, then at 412, the UE will includethe previously provided network eDRX parameters in the attach or TAUrequest.

FIG. 5 presents an example UE 500 configured to employ an eDRX retryprotocol in association with negotiating eDRX parameters between the UEand the network in accordance with various aspects and embodiments ofthe subject disclosure. In various embodiments, the UE 102 of system 100can be or include UE 500, or vice versa. Repetitive description of likeelements employed in respective embodiments is omitted for sake ofbrevity.

The UE can include memory 502 configured to store computer executablecomponents and instructions. For example, in various embodiments, thesecomputer executable components and instructions can include one or moreeDRX components 504. The one or more eDRX components 504 can includeinformation and instructions that control one or more defined eDRXoperations of the UE. For example, the eDRX components 504 can includeinformation and instructions regarding when the UE should employ eDRXmode. In another example, the eDRX components 504 can includeinformation and instructions that define preferred or default UE eDRXparameter values, such as a preferred eDRX timer value for the eDRXperiod, a total duration for the idle period, timer values associatedwith the paging period, and the like. In another example, the eDRXcomponents 504 can include information and instructions that control howthe UE can execute eDRX mode, such as instructions regarding how torequest eDRX mode in an attach or TAU request, and how to enter intoeDRX mode based on reception of attach or TAU acceptance messagesincluding network eDRX parameters. The UE 500 can also include aprocessor 506 to facilitate operation of the instructions (e.g., thecomputer executable components and instructions) by the UE (e.g., theone or more eDRX components 504). The UE 500 further includes acommunication component 508, a power source 510, an integrated circuit(IC) card 514 and a device bus 512. The device bus 512 can couple thevarious components of the UE 500 including, but not limited to, thememory 502, the processor 506, the communication component 508, thepower source 510, and the IC card 514. Examples of said processor 506and memory 502, as well as other suitable computer or computing-basedelements that can be employed by the UE, can be found with reference toFIG. 11.

The communication component 508 can facilitate wireless communicationbetween the UE and other devices, such as between the UE 500 and otherUEs via an M2M link and/or between the UE 500 and a wirelesscommunication system network node (e.g., network node 104). Thecommunication component 508 can be or include hardware (e.g., a centralprocessing unit (CPU), one or more transmitters, one or more receivers,one or more transceivers, one or more decoders), software (e.g., a setof threads, a set of processes, software in execution) or a combinationof hardware and software that facilitates one or more of the varioustypes of wireless communications described herein. The power source 510can provide power to the various electrical components of the UE 500 tofacilitate operation thereof (e.g., the processor 506, the communicationcomponent 508, the IC card 514, etc.). The power source 510 can include,but is not limited to, a battery, a capacitor, a charge pump, amechanically derived power source (e.g., microelectromechanical systems(MEMs) device), or an induction component.

The IC card 514 can include a fixed or removable integrated circuitchip. The IC card can include memory 516 that stores information andcomputer executable components or instructions. In the embodiment shown,these computer executable components can include the eDRX retrycomponent 518. In other embodiments, the eDRX retry component 518(and/or one or more sub-components of the eDRX retry component 518) canbe provided in memory 502. In another embodiment, one or more of theeDRX components 504 can be provided in memory 516 of the IC card 514. Insome embodiments, the IC card 514 can include a micro-processor 526 tofacilitate operation of at least some the instructions stored in thememory 516 (e.g., the eDRX retry component 518). In other embodiments,the UE can be configured to employ processor 506 to execute theinstructions stored in memory 516 (e.g., the eDRX retry component 518).

In one or more embodiments, the IC card 514 is a SIM card or a UICC thatstores network subscriber data (not shown) that includesnetwork-specific information used to authenticate and identify asubscriber on a wireless communication network (e.g., system 100). Theterms SIM card and UICC are used herein interchangeably to refer to anintegrated circuit card that provides same or similar features andfunctionalities when employed in association with a UE that isconfigured to operate using a wireless communication network. Ingeneral, the SIM card and the UICC can contain unique information thatidentifies a UE to a wireless communication network with which the SIMcard or UICC is registered and enables the UE to operate using thewireless communication network. For example, the network subscriber datacan include but is not limited to, a unique serial number (ICCID)associated with the subscriber, an IMEI number associated with thesubscriber, security authentication and ciphering information, temporaryinformation related to the local network, a list of the services thesubscriber has access to, and password information (e.g., a personalidentification number (PIN) for ordinary use, and a personal unblockingcode (PUK) for PIN unlocking. The UICC is considered a next generationSIM card and has applications beyond GSM networks. In addition tostoring network subscriber data, the IC card 514 can include one or moreSIM application toolkit (STK) or card application toolkit (CAT)applications that consist of a set of commands programmed into theSIM/UICC card which define how the SIM/UICC should interact directlywith the outside world and initiates commands independently of the UEand the network. This enables the SIM/UICC to build up an interactiveexchange between a network application and the end user and access orcontrol access to the network. In one or more embodiments, at least oneof these STK or CAT applications can be or include the eDRX retrycomponent 518.

In accordance with various embodiments, the eDRX retry component 518 canprovide the subject eDRX retry protocol that controls the maximum numberof times (N-max) the UE 102 can negotiate UE desired eDRX parameterswith the core wireless communication network (via a network device 108of the core wireless communication network 106, such as an MME device),after the network has previously instructed the UE 102 to use networkeDRX parameters that are different from the UE requested eDRXparameters. In some implementations, the eDRX retry component 518 and beenabled or disabled, wherein when enabled, the UE is be configured toexecute the eDRX retry protocol (e.g., using micro-processor 526 orprocessor 506), and wherein when disabled, the UE is be configured tonegotiate eDRX parameters without the subject eDRX retry protocol (e.g.,according to the protocol defined by the one or more eDRX components504). For example, the eDRX retry component 518 can include a retry flagthat can be set to a first value (e.g., one) to enable the eDRX retryfunctionality of the eDRX retry component 518 or a second value (e.g.,zero) to disable the eDRX retry functionality. In one or moreembodiments, the core wireless communication network (e.g., a networkdevice 108 of the core wireless communication network 106) can controlenabling and disabling the eDRX retry component 518 using an OTAmessage.

In various embodiments, the eDRX retry component 518 can include retrytracking component 520, eDRX parameter control component 522, and eDRXparameter information 524. When the eDRX retry component 518 is enabled,the retry tracking component 520 can be configured to track the numberof times N the UE sends an attach or TAU request with UE preferred eDRXparameters yet is instructed by the network, via the attach or TAUacceptance message, to employ network eDRX parameters that are differentfrom the UE requested eDRX parameters. The retry tracking component 520can further store information regarding the number of “failed” eDRXnegotiation attempts, N, in memory 516 (e.g., as eDRX parameterinformation 524). In some implementations, the information regarding thenumber of failed eDRX negotiation attempts can merely include thetracked number N. In other implementations, the retry tracking component520 can further store information in memory 516 (e.g., as eDRX parameterinformation 524), that identifies the specific network provided eDRXparameter values that were applied by the UE in response to the failedeDRX negotiation procedure. The retry tracking component 520 can alsostore, as eDRX parameter information, information identifying the UEpreferred eDRX parameter values that were rejected by the network.

The eDRX parameter control component 522 can be configured to controlwhat eDRX parameters the UE provides in each attach or TAU request. Inparticular, each time the UE initiates an attach or TAU request, whenthe eDRX retry component 518 is enabled, the eDRX parameter controlcomponent 522 can determine whether the value N (included in the eDRXparameter information 524) is greater than or equal to N-max. The valueN-max can also be included in memory 516 (e.g., in the eDRX parameterinformation 524) and accessible to the eDRX parameter control component522. In some implementations, the network (e.g., core wirelesscommunication network 106) can set the value N-max. For example, thenetwork can send the UE 500 an OTA message that that directs the UE 500to set N-Max to a specific value (e.g., 5). In response to adetermination that N is less than N-max, the eDRX parameter controlcomponent 522 can direct or authorize the UE to include UE preferredeDRX parameter values in the attach/TAU request. However, in response toa determination that N is greater than N-max, the eDRX parameter controlcomponent 522 can direct the UE to include, in the attach/TAU request,the network eDRX parameter values that were most recently previouslyprovided to the UE by the network and employed by the UE. Informationidentifying the most recently previously provided and employed networkeDRX parameter values can be stored in memory 516 (e.g., as eDRXparameter information 524).

The retry tracking component 520 can further be configured to reset thecount N to a default value (e.g., zero) in response to a UE reset, powerrecycle, re-boot, enter/exit airplane mode, and the like. In someimplementations, the core wireless communication network can also resetthe count N to its default value or another value (e.g., using an OTAmessage). For example, in one implementation, the network may determinethat the UE should forgo any possible remaining eDRX parameternegotiation attempts allowed and begin only using the network eDRXparameter values. According to this implementation, the network can sendthe UE an OTA message that causes the UE to increase N to be greaterthan the N-Max value or to set the N-Max value to a lower value that isless than the current N value.

In some implementations, the network can also provide the UE with newnetwork eDRX parameter values. For example, the network may respond to aUE attach or TAU request comprising network eDRX parameters with anattach/TAU acceptance message with new network eDRX parameters.According to this implementation, as defined in the 3GGP Release 13specification, the UE is still required to honor the new network eDRXparameters included in the attach/TAU response. Accordingly, the UE willoperate in eDRX mode according to the new network eDRX parameters. Inaddition, the retry tracking component 520 can include information inthe eDRX parameter information 524 identifying the new network eDRXparameters. In the next attach/TAU request, the eDRX parameter controlcomponent 522 can direct the UE to employ the new network eDRXparameters if N is greater than or equal to N-max.

FIG. 6 presents an example network device 600 configured to facilitatemanaging negotiation of eDRX parameters between a UE the network devicein accordance with various aspects and embodiments of the subjectdisclosure. In various embodiments, a network device of the one or morenetwork devices 108 of system 100 can be or include network device 600,or vice versa. In one implementation, the network device 600 is an MMEdevice. Still in other embodiments, one or more components of thenetwork device 600 can be included at the network node (e.g., networknode) that connects a UE to the core wireless communication network(e.g., core wireless communication network 106). Repetitive descriptionof like elements employed in respective embodiments is omitted for sakeof brevity.

The network device 600 can include various components that facilitatemanaging negotiation of eDRX parameters between the network device 600and a UE (e.g., UE 102, UE 500 and the like). These components caninclude eDRX retry control component 602, request reception component604, requested eDRX parameter evaluation component 606, eDRX parameterassignment component 608 and eDRX parameter tracking component 612. Thenetwork device 600 can include memory to store computer executablecomponents and instructions (e.g., the eDRX retry control component 602,the request reception component 604, the requested eDRX parameterevaluation component 606, the eDRX parameter assignment component 608,and the eDRX parameter tracking component 612). The network device 600can also include a processor 614 to facilitate operation of the computerexecutable instructions (e.g., the computer executable components andinstructions) by the network device 600. The network device 600 canfurther include a device bus 610 that couples the various components ofthe network device, including, but not limited to: the eDRX retrycontrol component 602, the request reception component 604, therequested eDRX parameter evaluation component 606, the eDRX parameterassignment component 608, and the eDRX parameter tracking component 612,the memory 616 and the processor 614. Examples of said processor 614 andmemory 616, as well as other suitable computer or computing-basedelements that can be employed by the network device 600, can be foundwith reference to FIG. 11.

In one or more embodiments, the eDRX retry control component 602 can beconfigured to control various aspects of the eDRX retry control protocoldeployed at respective UEs (e.g., on the UE SIM/UICC) serviced by thewireless communication network associated with the network device 600.For example, in some implementations, the eDRX retry control component602 can control activating/enabling and deactivating/disabling the eDRXretry protocol functionality at respective UEs. In embodiments in whichthe eDRX retry control protocol functionality is provided on the SIMcard or UICC of the UE, the eDRX retry control component 602 can directthe network device 600 to send the UE an OTA message that eitheractivates or deactivates the retry control functionality at the UE(e.g., the eDRX retry component 518). For example, the OTA message candirect the UE either to set an eDRX retry control flag value to zero orone, thereby disabling or enabling the eDRX retry component 518. TheeDRX retry control component 602 can also control the threshold valueN-Max employed by the UE eDRX retry component (e.g., eDRX retrycomponent 518). For example, in embodiments in which the eDRX retrycontrol protocol functionality is provided on the SIM card or UICC ofthe UE, the eDRX retry control component 602 can direct the networkdevice 600 to send the UE an OTA message that defines the N-Max valuefor application by the eDRX retry component (e.g., eDRX retry component518). In some embodiments, the eDRX retry control component 602 can alsocontrol resetting N back to its default value (e.g., zero) or anothervalue.

The request reception component 604 can be configured to receive attachand TAU requests sent by a UE. In response to a determination that anattach or TAU request comprises eDRX parameter values and thus includesa request to enter eDRX mode by the UE, the request reception component604 can forward the request to the requested eDRX parameter evaluationcomponent 606. The requested eDRX parameter evaluation component 606 canbe configured to evaluate eDRX parameters included in a UE attach or TAUrequest to determine whether to authorize performance of eDRX mode bythe UE. Based on a determination the UE is authorized to operate in eDRXmode, the requested eDRX parameter evaluation component 606 can furtherbe configured to determine what eDRX parameter values the UE can apply.

In accordance with one or more embodiments, the network device 600 canstore UE eDRX parameter information 618 in memory 616 to facilitatedetermining what eDRX parameters the UE can apply. For example, the UEeDRX parameter information can include a look-up table that identifiesUEs service by the network device 600. The look-up table can alsoinclude information that identifies network eDRX parameters that thenetwork has previously determined the UE should apply when operating ineDRX mode. For example, in response to reception of an attach or TAUrequest from a UE including eDRX parameters, the requested eDRXparameter evaluation component 606 can be configured to examine the UEeDRX parameter information 618 to determine whether the UE is includedin the look-up table and whether the UE is associated with network eDRXparameter information.

In implementations in which the UE is included in the look-up table andis associated with network eDRX parameter information, the requestedeDRX parameter evaluation component 606 can compare the requested UEeDRX parameter value(s) with the network eDRX parameter valuesassociated with the UE. In response to a determination that therequested UE eDRX parameter values and the network eDRX parameter valuesare the same, the requested eDRX parameter evaluation component 606 candirect the eDRX parameter assignment component 608 to send the UE anattach or TAU acceptance message including the network eDRX parametervalues. However, in response to a determination that the requested UEeDRX parameter values and the network eDRX parameter values aredifferent, the requested eDRX parameter evaluation component 606 can beconfigured to perform an evaluation process to determine whether toauthorize the UE to employ the requested UE eDRX parameter values. Forexample, the requested eDRX parameter evaluation component 606 determinewhether application of the UE eDRX parameter values by the UE issuitable in view of current network load (e.g., or load of the networkdevice 600), current network signal scheduling constraints, and othernetwork related factors.

Based on this evaluation process, in response to a determination by therequested eDRX parameter evaluation component 606 that the UE can employits requested UE eDRX parameter values, the requested eDRX parameterevaluation component 606 can direct the eDRX parameter assignmentcomponent 608 to send the UE an attach or TAU acceptance messageincluding the requested UE eDRX parameter values. However, if therequested eDRX parameter evaluation component 606 determines that therequested UE eDRX parameter values are not appropriate, in oneembodiment, the requested eDRX parameter evaluation component 606 candirect the eDRX parameter assignment component 608 to send the UE anattach or TAU acceptance message including the network eDRX parametervalues that are defined in the look-up table. In another embodiment, therequested eDRX parameter evaluation component 606 can determine newnetwork eDRX parameter values that the UE should employ in view ofcurrent network conditions. According to this embodiment, the requestedeDRX parameter evaluation component 606 can direct the eDRX parameterassignment component 608 to send the UE an attach or TAU acceptancemessage including the new network eDRX parameter values. The eDRXparameter tracking component 612 can further update the look-up table toinclude the new network eDRX parameter values for the UE.

In implementations in which the UE is not included in the look-up tableand/or is not associated with network eDRX parameter information, therequested eDRX parameter evaluation component 606 can be configured toperform the aforementioned evaluation process to determine whether toauthorize the UE to use the UE requested eDRX parameter values.According to this implementation, based on the evaluation process, inresponse to a determination that the UE can employ its requested UE eDRXparameter values, the requested eDRX parameter evaluation component 606can direct the eDRX parameter assignment component 608 to send the UE anattach or TAU acceptance message including the requested UE eDRXparameter values. The eDRX parameter tracking component 612 can furtherenter information into the look-up table (e.g., the UE eDRX parameterinformation 618), associating the UE with the assigned eDRX parametervalues. However, if the requested eDRX parameter evaluation component606 determines that the requested UE eDRX parameter values are notappropriate, the requested eDRX parameter evaluation component 606 candetermine network approved eDRX parameter values that the UE shouldemploy in view of current network conditions. According to thisembodiment, the requested eDRX parameter evaluation component 606 candirect the eDRX parameter assignment component 608 to send the UE anattach or TAU acceptance message including network eDRX parametervalues. The eDRX parameter tracking component 612 can further update thelook-up table to include information associating the UE with the networkeDRX parameter values.

With the subject configuration, if a UE provides the network device 600with eDRX parameter values that are the same as those associated withthe UE in the UE eDRX parameter information 618 (e.g., the UE providesnetwork eDRX parameter values as opposed to UE preferred eDRX parametervalues), the requested eDRX parameter evaluation component 606 does notneed to perform an evaluation process to determine whether to authorizethe UE requested eDRX parameter values. The eDRX parameter assignmentcomponent 608 can simply respond to the attach or TAU request with thesame parameters requested by the UE. In one or more additionalembodiments, in these scenarios, rather than always responding to the UEwith the previously approved network eDRX parameters, the requested eDRXparameter evaluation component 606 can be configured to periodicallyre-evaluate the network eDRX parameters requested by the UE.

For example, in one embodiment, the requested eDRX parameter evaluationcomponent 606 can be configured to re-evaluate the network eDRXparameters requested by the UE according to a predetermined schedule(e.g., once a day, once a week, etc.). In another example, the requestedeDRX evaluation component 606 can be configured to re-evaluate thenetwork eDRX parameters requested by the UE in response to a change innetwork conditions, such as change in network load relative to athreshold degree of deviation. In another example, the eDRX parametertracking component 612 can be configured to track the number of times(M) a UE includes network eDRX parameters in an attach or TAU request,thereby causing the eDRX parameter assignment component 608 toautomatically respond to the request by including the network eDRXparameters in the attach or TAU response. According to this example, therequested eDRX evaluation component 606 can employ a threshold number(M-max) that limits the number of times the eDRX parameter assignmentcomponent 608 can automatically respond with the network eDRX parametervalues before re-evaluating the network eDRX parameter values. Forexample, in association with reception of an attach or TAU request froma UE including network eDRX parameter values, if M is greater thanM-max, the requested eDRX parameter evaluation component 606 can beconfigured to re-evaluate the network eDRX parameters requested by theUE. According to this example, the requested eDRX parameter evaluationcomponent 606 may determine new network eDRX parameter values for theUE, update the look-up table with the new network eDRX parameter values,and direct the eDRX parameter assignment component 608 to send the UEand attach or TAU response with the new network eDRX parameter values.

In view of the example system(s) described above, example method(s) thatcan be implemented in accordance with the disclosed subject matter canbe better appreciated with reference to flowcharts in FIGS. 7-9. Forpurposes of simplicity of explanation, example methods disclosed hereinare presented and described as a series of acts; however, it is to beunderstood and appreciated that the claimed subject matter is notlimited by the order of acts, as some acts may occur in different ordersand/or concurrently with other acts from that shown and describedherein. For example, one or more example methods disclosed herein couldalternatively be represented as a series of interrelated states orevents, such as in a state diagram. Moreover, interaction diagram(s) mayrepresent methods in accordance with the disclosed subject matter whendisparate entities enact disparate portions of the methods. Furthermore,not all illustrated acts may be required to implement a describedexample method in accordance with the subject specification. Furtheryet, two or more of the disclosed example methods can be implemented incombination with each other, to accomplish one or more aspects hereindescribed. It should be further appreciated that the example methodsdisclosed throughout the subject specification are capable of beingstored on an article of manufacture (e.g., a computer-readable medium)to allow transporting and transferring such methods to computers forexecution, and thus implementation, by a processor or for storage in amemory.

FIG. 7 illustrates another example method 700 for managing negotiationof eDRX parameters between a UE and core network device in accordancewith various aspects and embodiments of the subject disclosure.Repetitive description of like elements employed in respectiveembodiments is omitted for sake of brevity.

At 702, a device comprising a processor (e.g., a UE 102, UE 500 or thelike), establishes a wireless communication link with a network deviceof a wireless network. For example, the UE can connect to a core networkdevice (e.g., a network device 108, 600 or the like), via a network nodeof the wireless communication network in association with performing anattachment procedure or a TAU procedure. At 704, the device determines,based on a determination that an idle mode retry protocol for the deviceis enabled (e.g., based on enablement of eDRX retry component 518), anumber of times (N) the network device has previously instructed thedevice to use a network value for an idle mode parameter instead of adevice value for the idle mode parameter in association with the deviceoperating in an idle mode. For example, the UE can determine a number oftimes (N) the network device has previously instructed the UE to employa network eDRX timer as opposed to a UE preferred eDRX timer. In oneimplementation, if N is less than N-Max, the UE can request usage or theUE preferred eDRX timer in the attachment or TAU request. Otherwise, theUE can be configured to include the previously received network eDRXtimer value attachment of TAU request.

FIG. 8 illustrates another example method 800 for managing negotiationof eDRX parameters between a UE and core network device in accordancewith various aspects and embodiments of the subject disclosure.Repetitive description of like elements employed in respectiveembodiments is omitted for sake of brevity.

At 802, a device comprising a processor (e.g., a UE 102, UE 500 or thelike), determines a number of times (N) the device was previouslyinstructed by a network device (e.g., a network device 108, networkdevice 600 and the like) of a wireless communication network to use anetwork timer value for a discontinuous reception period of and idlemode instead of a device timer value for the discontinuous receptionperiod in association with the device operating in the idle mode. At804, the device sends a first request to the network device requestingusage of the device timer value in association with the device operatingin the idle mode based on the number being less than a threshold retrynumber (N-Max). At 806, the device sends a second request to the networkdevice requesting usage of the network timer value in association withthe device operating in the idle mode based on the number being greaterthan or equal to the threshold retry number.

FIG. 9 illustrates another example method 900 for managing negotiationof eDRX parameters between a UE and core network device in accordancewith various aspects and embodiments of the subject disclosure.Repetitive description of like elements employed in respectiveembodiments is omitted for sake of brevity.

At 902, an integrated circuit card device comprising a processor (e.g.,IC card 514), activates an idle mode retry control protocol based onreception, by a device operatively coupled to the integrated circuitcard device (e.g., UE 500), of an OTA message from a network device(e.g., network device 108, 600 and the like) of a wireless communicationnetwork, wherein the OTA message comprises retry control informationdirecting the integrated circuit card device to activate the idle moderetry control protocol and defining a threshold retry number (N-Max). At904, based on the activating, the integrated circuit card devicedetermines a number of times the device was previously instructed by thenetwork device to use a network value for an idle mode parameter insteadof a device value for the idle mode parameter in association with thedevice operating in an idle mode. At 906, the integrated circuit carddevice directs the device to send a first request to the network devicerequesting usage of the device value in association with the operatingin the idle mode based on the number being less than the threshold retrynumber. At 908, the integrated circuit card device directs the device tosend a second request to the network device requesting usage of thenetwork value in association with the operating in the idle mode basedon the number being greater than or equal to the threshold retry number.

FIG. 10 is a schematic block diagram of a computing environment 1000with which the disclosed subject matter can interact. The system 1000comprises one or more remote component(s) 1010. The remote component(s)1010 can be hardware and/or software (e.g., threads, processes,computing devices). In some embodiments, remote component(s) 1010 cancomprise servers, personal servers, wireless telecommunication networkdevices, RAN device(s), etc. As an example, remote component(s) 1010 canbe network node 104, network devices 108, network device 600 and thelike. The system 1000 also comprises one or more local component(s)1020. The local component(s) 1020 can be hardware and/or software (e.g.,threads, processes, computing devices). In some embodiments, localcomponent(s) 1020 can comprise, for example, UE 102, UE 500, and thelike.

One possible communication between a remote component(s) 1010 and alocal component(s) 1020 can be in the form of a data packet adapted tobe transmitted between two or more computer processes. Another possiblecommunication between a remote component(s) 1010 and a localcomponent(s) 1020 can be in the form of circuit-switched data adapted tobe transmitted between two or more computer processes in radio timeslots. The system 1000 comprises a communication framework 1040 that canbe employed to facilitate communications between the remote component(s)1010 and the local component(s) 1020, and can comprise an air interface,e.g., Uu interface of a UMTS network, via an LTE network, etc. Remotecomponent(s) 1010 can be operably connected to one or more remote datastore(s) 1050, such as a hard drive, solid state drive, SIM card, devicememory, etc., that can be employed to store information on the remotecomponent(s) 1010 side of communication framework 1040. Similarly, localcomponent(s) 1020 can be operably connected to one or more local datastore(s) 1030, that can be employed to store information on the localcomponent(s) 1020 side of communication framework 1040.

In order to provide a context for the various aspects of the disclosedsubject matter, FIG. 11, and the following discussion, are intended toprovide a brief, general description of a suitable environment in whichthe various aspects of the disclosed subject matter can be implemented.While the subject matter has been described above in the general contextof computer-executable instructions of a computer program that runs on acomputer and/or computers, those skilled in the art will recognize thatthe disclosed subject matter also can be implemented in combination withother program modules. Generally, program modules comprise routines,programs, components, data structures, etc. that performs particulartasks and/or implement particular abstract data types.

In the subject specification, terms such as “store,” “storage,” “datastore,” data storage,” “database,” and substantially any otherinformation storage component relevant to operation and functionality ofa component, refer to “memory components,” or entities embodied in a“memory” or components comprising the memory. It is noted that thememory components described herein can be either volatile memory ornonvolatile memory, or can comprise both volatile and nonvolatilememory, by way of illustration, and not limitation, volatile memory 1120(see below), non-volatile memory 1122 (see below), disk storage 1124(see below), and memory storage 1146 (see below). Further, nonvolatilememory can be included in read only memory, programmable read onlymemory, electrically programmable read only memory, electricallyerasable read only memory, or flash memory. Volatile memory can compriserandom access memory, which acts as external cache memory. By way ofillustration and not limitation, random access memory is available inmany forms such as synchronous random access memory, dynamic randomaccess memory, synchronous dynamic random access memory, double datarate synchronous dynamic random access memory, enhanced synchronousdynamic random access memory, Synchlink dynamic random access memory,and direct Rambus random access memory. Additionally, the disclosedmemory components of systems or methods herein are intended to comprise,without being limited to comprising, these and any other suitable typesof memory.

Moreover, it is noted that the disclosed subject matter can be practicedwith other computer system configurations, comprising single-processoror multiprocessor computer systems, mini-computing devices, mainframecomputers, as well as personal computers, hand-held computing devices(e.g., personal digital assistant, phone, watch, tablet computers,notebook computers, . . . ), microprocessor-based or programmableconsumer or industrial electronics, and the like. The illustratedaspects can also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network; however, some if not all aspects ofthe subject disclosure can be practiced on stand-alone computers. In adistributed computing environment, program modules can be located inboth local and remote memory storage devices.

FIG. 11 illustrates a block diagram of a computing system 1100 operableto execute the disclosed systems and methods in accordance with anembodiment. Computer 1112, which can be, for example, a UE (e.g., UE 102and 500), a network node (e.g., network node 104), a core network device(e.g., network device 108, network device 600 and the like) comprises aprocessing unit 1114, a system memory 1116, and a system bus 1118.System bus 1118 couples system components comprising, but not limitedto, system memory 1116 to processing unit 1114. Processing unit 1114 canbe any of various available processors. Dual microprocessors and othermultiprocessor architectures also can be employed as processing unit1114.

System bus 1118 can be any of several types of bus structure(s)comprising a memory bus or a memory controller, a peripheral bus or anexternal bus, and/or a local bus using any variety of available busarchitectures comprising, but not limited to, industrial standardarchitecture, micro-channel architecture, extended industrial standardarchitecture, intelligent drive electronics, video electronics standardsassociation local bus, peripheral component interconnect, card bus,universal serial bus, advanced graphics port, personal computer memorycard international association bus, Firewire (Institute of Electricaland Electronics Engineers 11104), and small computer systems interface.

System memory 1116 can comprise volatile memory 1120 and nonvolatilememory 1122. A basic input/output system, containing routines totransfer information between elements within computer 1112, such asduring start-up, can be stored in nonvolatile memory 1122. By way ofillustration, and not limitation, nonvolatile memory 1122 can compriseread only memory, programmable read only memory, electricallyprogrammable read only memory, electrically erasable read only memory,or flash memory. Volatile memory 1120 comprises read only memory, whichacts as external cache memory. By way of illustration and notlimitation, read only memory is available in many forms such assynchronous random access memory, dynamic read only memory, synchronousdynamic read only memory, double data rate synchronous dynamic read onlymemory, enhanced synchronous dynamic read only memory, Synchlink dynamicread only memory, Rambus direct read only memory, direct Rambus dynamicread only memory, and Rambus dynamic read only memory.

Computer 1112 can also comprise removable/non-removable,volatile/non-volatile computer storage media. FIG. 11 illustrates, forexample, disk storage 1124. Disk storage 1124 comprises, but is notlimited to, devices like a magnetic disk drive, floppy disk drive, tapedrive, flash memory card, or memory stick. In addition, disk storage1124 can comprise storage media separately or in combination with otherstorage media comprising, but not limited to, an optical disk drive suchas a compact disk read only memory device, compact disk recordabledrive, compact disk rewritable drive or a digital versatile disk readonly memory. To facilitate connection of the disk storage devices 1124to system bus 1118, a removable or non-removable interface is typicallyused, such as interface 1126.

Computing devices typically comprise a variety of media, which cancomprise computer-readable storage media or communications media, whichtwo terms are used herein differently from one another as follows.

Computer-readable storage media can be any available storage media thatcan be accessed by the computer and comprises both volatile andnonvolatile media, removable and non-removable media. By way of example,and not limitation, computer-readable storage media can be implementedin connection with any method or technology for storage of informationsuch as computer-readable instructions, program modules, structureddata, or unstructured data. Computer-readable storage media cancomprise, but are not limited to, read only memory, programmable readonly memory, electrically programmable read only memory, electricallyerasable read only memory, flash memory or other memory technology,compact disk read only memory, digital versatile disk or other opticaldisk storage, magnetic cassettes, magnetic tape, magnetic disk storageor other magnetic storage devices, or other tangible media which can beused to store desired information. In this regard, the term “tangible”herein as may be applied to storage, memory or computer-readable media,is to be understood to exclude only propagating intangible signals perse as a modifier and does not relinquish coverage of all standardstorage, memory or computer-readable media that are not only propagatingintangible signals per se. In an aspect, tangible media can comprisenon-transitory media wherein the term “non-transitory” herein as may beapplied to storage, memory or computer-readable media, is to beunderstood to exclude only propagating transitory signals per se as amodifier and does not relinquish coverage of all standard storage,memory or computer-readable media that are not only propagatingtransitory signals per se. Computer-readable storage media can beaccessed by one or more local or remote computing devices, e.g., viaaccess requests, queries or other data retrieval protocols, for avariety of operations with respect to the information stored by themedium. As such, for example, a computer-readable medium can compriseexecutable instructions stored thereon that, in response to execution,cause a system comprising a processor to perform operations, comprisinggenerating an RRC connection release message further comprisingalternative band channel data.

Communications media typically embody computer-readable instructions,data structures, program modules or other structured or unstructureddata in a data signal such as a modulated data signal, e.g., a carrierwave or other transport mechanism, and comprises any informationdelivery or transport media. The term “modulated data signal” or signalsrefers to a signal that has one or more of its characteristics set orchanged in such a manner as to encode information in one or moresignals. By way of example, and not limitation, communication mediacomprise wired media, such as a wired network or direct-wiredconnection, and wireless media such as acoustic, RF, infrared and otherwireless media.

It can be noted that FIG. 11 describes software that acts as anintermediary between users and computer resources described in suitableoperating environment 1100. Such software comprises an operating system1128. Operating system 1128, which can be stored on disk storage 1124,acts to control and allocate resources of computer system 1112. Systemapplications 1130 take advantage of the management of resources byoperating system 1128 through program modules 1132 and program data 1134stored either in system memory 1116 or on disk storage 1124. It is to benoted that the disclosed subject matter can be implemented with variousoperating systems or combinations of operating systems.

A user can enter commands or information into computer 1112 throughinput device(s) 1136. In some embodiments, a user interface can allowentry of user preference information, etc., and can be embodied in atouch sensitive display panel, a mouse/pointer input to a graphical userinterface (GUI), a command line controlled interface, etc., allowing auser to interact with computer 1112. Input devices 1136 comprise, butare not limited to, a pointing device such as a mouse, trackball,stylus, touch pad, keyboard, microphone, joystick, game pad, satellitedish, scanner, TV tuner card, digital camera, digital video camera, webcamera, cell phone, smartphone, tablet computer, etc. These and otherinput devices connect to processing unit 1114 through system bus 1118 byway of interface port(s) 1138. Interface port(s) 1138 comprise, forexample, a serial port, a parallel port, a game port, a universal serialbus, an infrared port, a Bluetooth port, an IP port, or a logical portassociated with a wireless service, etc. Output device(s) 1140 use someof the same type of ports as input device(s) 1136.

Thus, for example, a universal serial bus port can be used to provideinput to computer 1112 and to output information from computer 1112 toan output device 1140. Output adapter 1142 is provided to illustratethat there are some output devices 1140 like monitors, speakers, andprinters, among other output devices 1140, which use special adapters.Output adapters 1142 comprise, by way of illustration and notlimitation, video and sound cards that provide means of connectionbetween output device 1140 and system bus 1118. It should be noted thatother devices and/or systems of devices provide both input and outputcapabilities such as remote computer(s) 1144.

Computer 1112 can operate in a networked environment using logicalconnections to one or more remote computers, such as remote computer(s)1144. Remote computer(s) 1144 can be a personal computer, a server, arouter, a network PC, cloud storage, a cloud service, code executing ina cloud-computing environment, a workstation, a microprocessor basedappliance, a peer device, or other common network node and the like, andtypically comprises many or all of the elements described relative tocomputer 1112. A cloud computing environment, the cloud, or othersimilar terms can refer to computing that can share processing resourcesand data to one or more computer and/or other device(s) on an as neededbasis to enable access to a shared pool of configurable computingresources that can be provisioned and released readily. Cloud computingand storage solutions can storing and/or processing data in third-partydata centers which can leverage an economy of scale and can viewaccessing computing resources via a cloud service in a manner similar toa subscribing to an electric utility to access electrical energy, atelephone utility to access telephonic services, etc.

For purposes of brevity, only a memory storage device 1146 isillustrated with remote computer(s) 1144. Remote computer(s) 1144 islogically connected to computer 1112 through a network interface 1148and then physically connected by way of communication connection 1150.Network interface 1148 encompasses wire and/or wireless communicationnetworks such as local area networks and wide area networks. Local areanetwork technologies comprise fiber distributed data interface, copperdistributed data interface, Ethernet, Token Ring and the like. Wide areanetwork technologies comprise, but are not limited to, point-to-pointlinks, circuit-switching networks like integrated services digitalnetworks and variations thereon, packet switching networks, and digitalsubscriber lines. As noted below, wireless technologies may be used inaddition to or in place of the foregoing.

Communication connection(s) 1150 refer(s) to hardware/software employedto connect network interface 1148 to bus 1118. While communicationconnection 1150 is shown for illustrative clarity inside computer 1112,it can also be external to computer 1112. The hardware/software forconnection to network interface 1148 can comprise, for example, internaland external technologies such as modems, comprising regular telephonegrade modems, cable modems and digital subscriber line modems,integrated services digital network adapters, and Ethernet cards.

The above description of illustrated embodiments of the subjectdisclosure, comprising what is described in the Abstract, is notintended to be exhaustive or to limit the disclosed embodiments to theprecise forms disclosed. While specific embodiments and examples aredescribed herein for illustrative purposes, various modifications arepossible that are considered within the scope of such embodiments andexamples, as those skilled in the relevant art can recognize.

In this regard, while the disclosed subject matter has been described inconnection with various embodiments and corresponding Figures, whereapplicable, it is to be understood that other similar embodiments can beused or modifications and additions can be made to the describedembodiments for performing the same, similar, alternative, or substitutefunction of the disclosed subject matter without deviating therefrom.Therefore, the disclosed subject matter should not be limited to anysingle embodiment described herein, but rather should be construed inbreadth and scope in accordance with the appended claims below.

As it employed in the subject specification, the term “processor” canrefer to substantially any computing processing unit or devicecomprising, but not limited to comprising, single-core processors;single-processors with software multithread execution capability;multi-core processors; multi-core processors with software multithreadexecution capability; multi-core processors with hardware multithreadtechnology; parallel platforms; and parallel platforms with distributedshared memory. Additionally, a processor can refer to an integratedcircuit, an application specific integrated circuit, a digital signalprocessor, a field programmable gate array, a programmable logiccontroller, a complex programmable logic device, a discrete gate ortransistor logic, discrete hardware components, or any combinationthereof designed to perform the functions described herein. Processorscan exploit nano-scale architectures such as, but not limited to,molecular and quantum-dot based transistors, switches and gates, inorder to optimize space usage or enhance performance of user equipment.A processor may also be implemented as a combination of computingprocessing units.

As used in this application, the terms “component,” “system,”“platform,” “layer,” “selector,” “interface,” and the like are intendedto refer to a computer-related entity or an entity related to anoperational apparatus with one or more specific functionalities, whereinthe entity can be either hardware, a combination of hardware andsoftware, software, or software in execution. As an example, a componentmay be, but is not limited to being, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program,and/or a computer. By way of illustration and not limitation, both anapplication running on a server and the server can be a component. Oneor more components may reside within a process and/or thread ofexecution and a component may be localized on one computer and/ordistributed between two or more computers. In addition, these componentscan execute from various computer readable media having various datastructures stored thereon. The components may communicate via localand/or remote processes such as in accordance with a signal having oneor more data packets (e.g., data from one component interacting withanother component in a local system, distributed system, and/or across anetwork such as the Internet with other systems via the signal). Asanother example, a component can be an apparatus with specificfunctionality provided by mechanical parts operated by electric orelectronic circuitry, which is operated by a software or firmwareapplication executed by a processor, wherein the processor can beinternal or external to the apparatus and executes at least a part ofthe software or firmware application. As yet another example, acomponent can be an apparatus that provides specific functionalitythrough electronic components without mechanical parts, the electroniccomponents can comprise a processor therein to execute software orfirmware that confers at least in part the functionality of theelectronic components.

In addition, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom context, “X employs A or B” is intended to mean any of the naturalinclusive permutations. That is, if X employs A; X employs B; or Xemploys both A and B, then “X employs A or B” is satisfied under any ofthe foregoing instances. Moreover, articles “a” and “an” as used in thesubject specification and annexed drawings should generally be construedto mean “one or more” unless specified otherwise or clear from contextto be directed to a singular form.

Further, the term “include” is intended to be employed as an open orinclusive term, rather than a closed or exclusive term. The term“include” can be substituted with the term “comprising” and is to betreated with similar scope, unless otherwise explicitly used otherwise.As an example, “a basket of fruit including an apple” is to be treatedwith the same breadth of scope as, “a basket of fruit comprising anapple.”

Moreover, terms like “user equipment (UE),” “mobile station,” “mobile,”subscriber station,” “subscriber equipment,” “access terminal,”“terminal,” “handset,” and similar terminology, refer to a wirelessdevice utilized by a subscriber or user of a wireless communicationservice to receive or convey data, control, voice, video, sound, gaming,or substantially any data-stream or signaling-stream. The foregoingterms are utilized interchangeably in the subject specification andrelated drawings. Likewise, the terms “access point,” “base station,”“Node B,” “evolved Node B,” “eNodeB,” “home Node B,” “home accesspoint,” and the like, are utilized interchangeably in the subjectapplication, and refer to a wireless network component or appliance thatserves and receives data, control, voice, video, sound, gaming, orsubstantially any data-stream or signaling-stream to and from a set ofsubscriber stations or provider enabled devices. Data and signalingstreams can comprise packetized or frame-based flows.

Additionally, the terms “core-network”, “core”, “core carrier network”,“carrier-side”, or similar terms can refer to components of atelecommunications network that typically provides some or all ofaggregation, authentication, call control and switching, charging,service invocation, or gateways. Aggregation can refer to the highestlevel of aggregation in a service provider network wherein the nextlevel in the hierarchy under the core nodes is the distribution networksand then the edge networks. UEs do not normally connect directly to thecore networks of a large service provider but can be routed to the coreby way of a switch or radio access network. Authentication can refer todeterminations regarding whether the user requesting a service from thetelecom network is authorized to do so within this network or not. Callcontrol and switching can refer determinations related to the futurecourse of a call stream across carrier equipment based on the callsignal processing. Charging can be related to the collation andprocessing of charging data generated by various network nodes. Twocommon types of charging mechanisms found in present day networks can beprepaid charging and postpaid charging. Service invocation can occurbased on some explicit action (e.g. call transfer) or implicitly (e.g.,call waiting). It is to be noted that service “execution” may or may notbe a core network functionality as third party network/nodes may takepart in actual service execution. A gateway can be present in the corenetwork to access other networks. Gateway functionality can be dependenton the type of the interface with another network.

Furthermore, the terms “user,” “subscriber,” “customer,” “consumer,”“prosumer,” “agent,” and the like are employed interchangeablythroughout the subject specification, unless context warrants particulardistinction(s) among the terms. It should be appreciated that such termscan refer to human entities or automated components (e.g., supportedthrough artificial intelligence, as through a capacity to makeinferences based on complex mathematical formalisms), that can providesimulated vision, sound recognition and so forth.

Aspects, features, or advantages of the subject matter can be exploitedin substantially any, or any, wired, broadcast, wirelesstelecommunication, radio technology or network, or combinations thereof.Non-limiting examples of such technologies or networks comprisebroadcast technologies (e.g., sub-Hertz, extremely low frequency, verylow frequency, low frequency, medium frequency, high frequency, veryhigh frequency, ultra-high frequency, super-high frequency, terahertzbroadcasts, etc.); Ethernet; X.25; powerline-type networking, e.g.,Powerline audio video Ethernet, etc.; femtocell technology; Wi-Fi;worldwide interoperability for microwave access; enhanced general packetradio service; third generation partnership project, long termevolution; third generation partnership project universal mobiletelecommunications system; third generation partnership project 2, ultramobile broadband; high speed packet access; high speed downlink packetaccess; high speed uplink packet access; enhanced data rates for globalsystem for mobile communication evolution radio access network;universal mobile telecommunications system terrestrial radio accessnetwork; or long term evolution advanced.

The term “infer” or “inference” can generally refer to the process ofreasoning about, or inferring states of, the system, environment, user,and/or intent from a set of observations as captured via events and/ordata. Captured data and events can include user data, device data,environment data, data from sensors, sensor data, application data,implicit data, explicit data, etc. Inference, for example, can beemployed to identify a specific context or action, or can generate aprobability distribution over states of interest based on aconsideration of data and events. Inference can also refer to techniquesemployed for composing higher-level events from a set of events and/ordata. Such inference results in the construction of new events oractions from a set of observed events and/or stored event data, whetherthe events, in some instances, can be correlated in close temporalproximity, and whether the events and data come from one or severalevent and data sources. Various classification schemes and/or systems(e.g., support vector machines, neural networks, expert systems,Bayesian belief networks, fuzzy logic, and data fusion engines) can beemployed in connection with performing automatic and/or inferred actionin connection with the disclosed subject matter.

What has been described above includes examples of systems and methodsillustrative of the disclosed subject matter. It is, of course, notpossible to describe every combination of components or methods herein.One of ordinary skill in the art may recognize that many furthercombinations and permutations of the claimed subject matter arepossible. Furthermore, to the extent that the terms “includes,” “has,”“possesses,” and the like are used in the detailed description, claims,appendices and drawings such terms are intended to be inclusive in amanner similar to the term “comprising” as “comprising” is interpretedwhen employed as a transitional word in a claim.

What is claimed is:
 1. A method, comprising: establishing, by a devicecomprising a processor, a wireless communication link with a networkdevice of a wireless network; and determining, by the device, based on adetermination that an idle mode retry protocol for the device isenabled, a number of times the network device has previously instructedthe device to use a network value for an idle mode parameter instead ofa device value for the idle mode parameter in association with thedevice operating in an idle mode.
 2. The method of claim 1, wherein theidle mode comprises an extended discontinuous reception idle mode. 3.The method of claim 1, wherein the operating in the idle mode comprises,after disconnecting from the network device, periodically activating areceiver of the device between discontinuous reception periods, whereinthe device deactivates the receiver.
 4. The method of claim 3, whereinthe idle mode parameter controls a duration of the discontinuousreception periods.
 5. The method of claim 4, wherein the duration of thediscontinuous reception periods is between one millisecond and one hour.6. The method of claim 1, wherein the determination is a firstdetermination, and further comprising: in response to a seconddetermination that the number of times does not exceed a threshold retrynumber, sending, by the device to the network device, a request to usethe device value for the idle mode parameter in association with thedevice operating in the idle mode.
 7. The method of claim 6, wherein thesending the request comprises sending an attachment message to thenetwork device via the wireless communication link, and wherein theattachment message comprises the device value for the idle modeparameter.
 8. The method of claim 6, wherein the sending the requestcomprises sending a tracking area update message to the network devicevia the wireless communication link, and wherein the tracking areaupdate message comprises the device value for the idle mode parameter.9. The method of claim 1, wherein the determination is a firstdetermination, and further comprising: in response to a seconddetermination that the number of times exceeds a threshold retry number,sending, by the device to the network device, a request to use thenetwork value for the idle mode parameter in association with the deviceoperating in the idle mode.
 10. The method of claim 9, wherein thenetwork value for the idle mode parameter was previously received by thedevice from the network device in response to a previous request,wherein the previous request was sent by the device to the networkdevice, for authorization to use the device value for the idle modeparameter in association with the device operating in the idle mode, andwherein the device previously employed the network value for the idlemode parameter in association with the device operating in the idlemode.
 11. The method of claim 9, wherein the sending the requestcomprises sending an attachment message to the network device via thewireless communication link, and wherein the attachment messagecomprises the network value for the idle mode parameter.
 12. The methodof claim 9, wherein the sending the request comprises sending a trackingarea update message to the network device via the wireless communicationlink, and wherein the tracking area update message comprises the networkvalue for the idle mode parameter.
 13. The method of claim 1, furthercomprising: receiving, by the device from the network device via thewireless communication link, retry control information defining athreshold number of times the network device is able to request a firstusage of the device value for the idle mode parameter after having beenpreviously instructed to use the network value for the idle modeparameter; and determining, by the device, based on a comparison of thenumber to the threshold number, whether to request the first usage ofthe device value or a second usage of the network value for the idlemode parameter in association with the device operating in the idlemode.
 14. An integrated circuit card device, comprising: a processor,and a memory that stores executable instructions that, when executed bythe processor, facilitate performance of operations, comprising: basedon a determination that an idle mode retry protocol is enabled,determining a number of times that a device, operatively coupled to theintegrated circuit card device, was previously instructed by a networkdevice of a wireless communication network to use a network value for anidle mode parameter instead of a device value for the idle modeparameter in connection with the device operating in an idle mode; anddirecting the device to send a request to the network device requestingusage of the device value in connection with the operating in the idlemode based on the number being determined to be less than a thresholdretry number.
 15. The integrated circuit card device of 14, wherein therequest is a first request and wherein the operations further comprise:directing the device to send a second request to the network devicerequesting usage of the network value in connection with the operatingin the idle mode based on the number being determined to be greater thanor equal to the threshold retry number.
 16. The integrated circuit carddevice of 15, wherein the network value for the idle mode parameter waspreviously received by the device from the network device in response toa previous request, which was sent by the device to the network device,wherein the previous request was for authorization to use the devicevalue for the idle mode parameter in connection with the deviceoperating in the idle mode, and wherein the device previously employedthe network value for the idle mode parameter in connection with thedevice operating in the idle mode.
 17. The integrated circuit carddevice of claim 14, wherein the operations further comprise: receiving,via an over the air message sent to the device by the network device,retry control information directing the integrated circuit card deviceto activate the idle mode retry control protocol and defining thethreshold retry number; activating the retry control protocol based onthe retry control information; and setting the threshold retry numberbased on the retry control information.
 18. The integrated circuit carddevice of claim 14, wherein the integrated circuit card device comprisesa subscriber identity module card.
 19. A machine-readable storagemedium, comprising executable instructions that, when executed by aprocessor of a device, facilitate performance of operations, comprising:determining a number of times the device was previously instructed by anetwork device of a wireless communication network to use a networktimer value for a discontinuous reception period of an idle mode insteadof a device timer value for the discontinuous reception period for whenthe device is operating in the idle mode; and sending a first request tothe network device requesting usage of the device timer value for whenthe device is operating in the idle mode based on the number beingdetermined to be less than a threshold retry number.
 20. Themachine-readable storage medium of claim 19, wherein the operationsfurther comprise: sending a second request to the network devicerequesting usage of the network timer value for when the deviceoperating in the idle mode based on the number being determined to beless greater than or equal to the threshold retry number.